Remote desktop products such as VMware® Horizon View™ allow users to remotely access virtual computing desktops, and applications running thereon, that are hosted on virtual machines (VMs) running in centralized servers and are delivered as a managed service to the users via a network. Such centralized and automated management of the virtualized operating system, applications, and user data provides increased control and cost savings.
Unauthenticated, or “anonymous,” logon is a feature that can permit users to connect to a remote desktop infrastructure and access remote desktops and applications without providing access credentials. For example, users at a healthcare facility may wish to access applications at different locations within the facility without having to log on at each of those locations. Although authentication is not required in unauthenticated remote desktop sessions, session isolation is still necessary to prevent users from accessing information in other users' sessions. Such session isolation may be achieved by having remote desktop users log on using different user accounts, with some information such as a template user profile being shared between accounts and other data being created and stored temporarily for each session.
In an unauthenticated remote desktop session, an application may need to access network resources, such as a file share hosted on another device or a network printer. A local logon, using an unauthenticated local account on the remote desktop host, would typically not permit such access to network resources unless the user provides additional network credentials. This requirement to provide credentials contradicts the purpose of unauthenticated access.
One solution to permitting unauthenticated remote desktop sessions access to network resources is to grant access to all users without authentication. For example, a guest account may be enabled in Microsoft Windows® that permissions resources to the “everyone” group, and, in such a case, anyone can access network resources without providing credentials. However, this approach may be undesirable for security reasons, as it creates an additional attack surface and can be used to discover information about the network environment.
Another approach is to create the same account on the network resource that is created locally on the remote desktop host. For example, the same usernames and passwords may be created on a network printer as on the remote desktop host. Operating systems such as Windows® automatically share the credentials used to log on locally with all authentication packages, including those for accessing network resources. As a result, the credentials used to log on locally could be used to access network resources on which the same account has been created. However, this approach requires the creation of the same accounts on all network devices to which access is desired and the synchronization of all the account passwords, which can be impractical.
Yet another approach is to create a set of domain accounts for accessing network resources, and to use those domain accounts rather than local accounts to log on to remote desktops. Doing so would provide unique accounts that can also be used to access network resources. However, the set of domain accounts would need to be maintained on potentially a large number of remote desktop hosts, which creates account management and overhead in ensuring a unique account is used for each session (to prevent to unauthorized access to data generated in a concurrent session if unique accounts are not used).